home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re MacApp to ODF conversion < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.1 KB  |  [TEXT/ttxt]
  1. Subject:     Re: MacApp to ODF conversion
  2. Sent:        5/3/96 6:20 PM
  3. Received:    5/6/96 8:55 AM
  4. From:        Brian Arnold, arnold@lumina.com
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >Has anyone out there tried to convert a MacApp project to an ODF project?
  9. >Tips, opinions, suggestions, caveats, mistakes would be appreciated.
  10.  
  11. Hi,
  12.  
  13. I haven't tried to convert so much as I've tried to plan to convert.  I'm
  14. waiting for ODF 1 to ship in a couple of weeks.  I'm going to WWDC to learn
  15. as much as I can about the recent changes to ODF.  Here's what I did to
  16. prepare.
  17.  
  18. 1. I extracted engine functionality from my app and converted the engine
  19.    code into a CFM shared library / Windows95 32-bit DLL [SOM wrapper tbd].
  20.    Plug: Metrowerks x86 got me running in just a couple of weeks, and
  21.    produced a faster executable than our previous Borland C++ build.
  22.  
  23. 2. I detangled user interface functionality, separating it out into
  24.    a non-MacApp-derived class hierarchy and a MacApp-derived class
  25.    hierarchy.  My motivation for this type of separation stemmed from
  26.    a previous, painful, aborted MacApp 2->3 upgrade.
  27.  
  28.    2.1 The non-MacApp classes are designed to be extensible mediators/
  29.        observers that use a singleton to represent the engine.
  30.    2.2 The MacApp subclasses act as (or with) proxies for the mediators.
  31.  
  32.    (I pulled out my "Design Patterns" book just to use those big words)
  33.  
  34.    An interesting thing happens when you do this.  The MacApp
  35.    subclasses tend to to MacApp things (or Toolbox things), and
  36.    the non-MacApp classes tend to to _app-specific_ and _platform-
  37.    independent_ things.  Although there are a lot more classes
  38.    compared to using a single MacApp-derived soup, you get a
  39.    flattening of hierarchy and better division of responsibilities.
  40.  
  41. 3. With this architecture, the only classes that die a horrible death
  42.    in a radical framework switch are the proxies.  I can then use ODF
  43.    to rapidly re-implement those proxies.  (Were it so simple! ;-)
  44.  
  45. 4. I toyed around with ODF d1, d6 and d9 to explore different ideas
  46.    about how to work with OpenDoc. To get the basic interface of my app
  47.    (sans gridviews, popups, etc., remember this was pre-release ODF)
  48.    would take about two days, largely re-implementing the menus
  49.    and windows from scratch and reusing sample part code.  I also learned
  50.    how to call my CFM library from OpenDoc, how to adapt ODF Draw to do
  51.    structured diagram editing, and how to drag a document created by my
  52.    MacApp application into my OpenDoc part, subsuming its contents.
  53.    Lastly, I learned that it's hard to track "d" releases with limited
  54.    time to spend on "R&D"; hence I look forward to ODF 1!
  55.  
  56. I can't say much about actually converting from MacApp to ODF until after
  57. WWDC, when I've had some time to work with ODF 1, but I hope these notes on
  58. what I'm doing to prepare are of some use.
  59.  
  60. - Brian
  61.  
  62. ---------------------------------------------------------------
  63. Brian Arnold                                  arnold@lumina.com
  64. Director of Software Development
  65. Lumina Decision Systems, Inc.            http://www.lumina.com/
  66.  
  67.